1.1. A qui est destiné ce document?

Les étudiants qui découvrent le langage, mes collègues enseignants qui cherchent un document de cours et d’exercice accessible, et … moi-même (pour organiser mes notes diverses)!

1.2. A qui n’est-il pas destiné?

Si vous appartenez à l’une de ces catégories, ce livre n’est pas pour vous :

• vous cherchez un livre de référence (pour cela, même s’il est en anglais, je conseille [FMS])
• vous voulez vous perfectionner (ce livre n’est qu’une introduction)
• vous souhaitez préparer la certification de l’OMG (mieux vaut vous plonger dans la spécification [SysML])

1.3. Historique

Ce document est la compilation de plusieurs années d’enseignement de SysML depuis 2007, que ce soit :

• au Master TI, de l’Université de Pau et des Pays de l’Adour (cours d’introduction avec mon collègue et ami Nicolas Belloir),
• au Master Recherche SAID, de l’UPS (introduction),
• au Master ICE de l’Université de Toulouse II - Le Mirail (introduction avec mon collègue et ami Pierre de Saqui Sannes),
• au Master of Science de Göteborg, Suède (introduction réalisée par Nicolas Belloir),
• à l’Universitad Autonoma de Guadalajara, au Mexique (40h de formation professionnelle aux employés de Continental),
• ou plus récemment au Master DL-SI de l’UPS.

Vous trouverez en référence (cf. Bibiliographie) les ouvrages et autres documents utilisés.

Je tiens à remercier mes collègues qui m’ont aidé dans mon entreprise :

• Nicolas Belloir de l’Université de Pau et des Pays de l’Adour, Laurent Nonne de l’IUT de Blagnac et Karina Aguilar de l’Universitad Autonoma de Guadalajara;
• mes collègues de SysML-France : Pascal Roques (PRFC), Agusti Canals (C-S) et Loïc Féjoz (RTaW);
• mon maître d’AsciiDoc : Jean-Michel Inglebert.

1.4. Sur l’auteur

• Professeur à l’Univesité de Toulouse
• Co-foundateur de l’association SysML-France
• Membre du comité éditorial de la revue Software and System Modeling journal
• Membre du Steering Committee de la conférence ACM/IEEE MODELS
• Chef du département informatique de l’IUT de Blagnac de 2009 à 2012
• Co-responsable de l’axe Systèmes Ambiants de l’IRIT
• Marié, une (merveilleuse) fille

1.5. Comment lire ce document?

1.5.1. Version électronique

Ce document a été réalisé de manière à être lu de préférence dans sa version électronique, ce qui permet de naviguer entre les références et les renvois interactivement, de consulter directement les documents référencés par une URL, etc.

Si vous lisez la version papier de ce document, ces liens clickables ne vous servent à rien, et c’est votre punition pour avoir utilisé du papier au lieu du support électronique!

1.6. Pourquoi parler de "document"?

Parce que j’ignore la version que vous êtes en train de lire. A partir de l’original, plusieurs versions ont été générées grâce à AsciiDoc:

• pour le web (Moodle) au format html
• pour présentation en amphi au format slidy ou deck.js
• pour impression au format pdf
• pour lire au format Kindle (bientôt!)

1.7. Utilisation et autres mentions légales

N’hésitez pas à m’envoyer vos remarques en tout genre en m'écrivant ici.

1.1. Points de vue

Dans un axe horizontal, j’ai différencié quatre grands points de vue :

1.2. Phase de développement

Dans un axe vertical, j’ai différencié quatre grandes phases du cycle de vie du développement :

2.1. Une ingénierie plus ancienne

Que ce soit généralement en terme de cycle de développement ou historiquement, l’Ingénierie Système arrive avant l’Ingénierie Logicielle. Les ingénieurs systèmes ont donc une longue expérience et des pratiques bien ancrées.

2.2. Des systèmes plus complexes

On parle de système complexe lorsque l’on a affaire à :

• un ensemble d'éléments humains et matériels en relation avec :
  • de nombreux éléments technologiques (Informatique, Hydraulique, Electronique, …)
  • intégrés pour fournir des services (finalité du système) en fonction de leur environnement
  • interagissant entre eux et avec leur environnement

On parle aussi de Système de systèmes quand un système :

• doit gérer les interactions entre ses parties (ou composantes)
• assure un comportement prévu à l’avance
• gère les comportements (de l’environnement) inatendus

2.3. Différents types d’analyse

Toute la question que l’Ingénierie Système cherche à résoudre est : comment passer des exigences au système de la façon la plus efficace possible.

Pour cela l’Ingénierie Système est découpée en plusieurs analyses, chacune avec un but bien particulier :

Pour arriver à combler le gap entre le système à développer et ses spécifications.

2.1. Fiche d’identité

• Date de naissance : 2001!
• Version actuelle : 1.3 (2/6/2012)
• Paternité : OMG/UML + INCOSE
• Auteurs principaux
  • Conrad Bock
  • Cris Kobryn
  • Sanford Friedenthal

Versions de la spécification de SysML La version 1.0 du langage de modélisation SysML a été adoptée officiellement par l’OMG le 19 septembre 2007. Depuis, trois révisions ont été réalisées : 1.1 en décembre 2008, 1.2 en juin 2010, et 1.3 en juin 2012.

2.2. Différence avec UML

2.3. Qui est "derrière"?

2.4. Organisation des différents diagrammes

2.5. Différence entre modèle et dessin

SysML n’est pas une palette de dessins et d'éléments de base servant à faire des diagrammes. Il existe une représentation graphique des éléments modélisés en SysML . Elle est importante car elle permet de communiquer visuellement sur le système en développement, mais du point de vue du concepteur, c’est le modèle qui importe le plus.

C’est pourquoi nous vous recommandons de ne jamais "dessiner" des diagrammes SysML
[Sauf bien sûr au brouillon ou sur un tableau, notamment quand on travaille en équipe.]
, mais d’utiliser des outils dédiés (cf. section [Outils]).

Pour ceux qui cherchent à étudier un diagramme en particulier voici un plan de cette section (nous utilisons ici le "plan" vu lors de l’introduction de la [Matrice]) :

5.1. Fondements

On abordera :

• Le Package Diagram
• Les différent types de packages
• Les organisations possibles
• La notion de Namespaces
• Les Dependencies

5.2. Le Package Diagram

• Identique à UML , et classique pour les développeurs (java notamment)
• Permet d’organiser les modèles en créant un espace de nommage (name space)

Espace de nommage Dans un package, on n’a pas à se soucier des noms des éléments. Même si d’autres utilisent les mêmes noms, il n’y aura pas ambiguité.

Les modèles peuvent être organisés selon toutes sortes de considération (cf. [organisation]). Le mécanisme qui permet de les organiser est le package (paquetage).

• hiérarchie "système" (e.g., entreprise, système, composant)
• types de diagrammes (e.g., besoins, structure, comportements)
• par points de vue
• etc.

5.3. Les différent types de packages

Il existe plusieurs types de package :

5.4. Les organisations possibles

Les modèles peuvent être organisés selon toutes sortes de considération :

• par hiérarchie "système" (e.g., entreprise, système, composant, …)
• par types de diagrammes (e.g., besoins, structure, comportements, …)
• par cycle de vie (e.g., analyse, conception, …)
• par équipes (e.g., architectes, [IPT], …)
• par points de vue (e.g., sécurité, performance, …)
• etc.

Organisation par défaut L’outil TOPCASED propose, lors de la création d’un premier modèle, de créer une organisation "type" par défaut. + +

5.5. La notion de Namespaces

Un package est un espace de nommage pour tous les éléments qu’il contient.

Dans les outils SysML , vous pouvez demander à voir les noms complets (Qualified names) des éléments, c’est à dire le nom de l'élément prefixé par son (ou ses) package(s) (e.g., Structure::Products::Clock).

5.6. Les dépendances

Un certain nombre de dépendances peuvent exister entre des éléments de package ou entre les packages eux-mêmes :

5.7. En résumé

SysML propose un certain nombre de mécanismes pour organiser les différents modèles, tirés pour la plupart d’UML .

5.8. Questions de révision

1. Quels sont les 5 types de dépendances entre packageable elements ?

2. A quoi sert-il de renseigner les dépendances (donnez des exemples concrets) ?

6.1. Fondements

On abordera :

• L’organization des Requirements
• Les Requirements properties
• Les Requirements links
• Les Requirements Diagrams
• Les considerations sur la Traceability
• Les Use Case Diagrams (scénarios)

L’ingénierie des exigences est une discipline à part entière et nous n’abordons ici que les aspects en lien avec la modélisation système. Voir le livre de référence pour plus de détails ([Sommerville1997]) ou le guide de l’AFIS ([REQ2012]).

6.2. L’organization des Requirements

Comme nous l’avons vu pour les packages, plusieurs types d’organisations sont possibles :

• Par niveau d’abstraction
  • Besoins généraux (en lien avec les use cases par exemple)
  • Besoins techniques (en lien avec les éléments de conception)
• Par point de vue
  • Besoins principaux (en lien avec les use cases)
  • Besoins spécifiques :
    • Fonctionnels
    • Marketing
    • Environnementaux
    • Business
    • …
• etc.

6.3. Les Requirements properties

Il est possible d’indiquer un certain nombre de propriétés sur un requirement :

• priority (high, low, …)
• source (stakeolder, law, technical, …)
• risk (high, low, …)
• status (proposed, aproved, …)
• verification method (analysis, tests, …)

6.4. Les Requirements links

Les principales relations entre requirement sont :

Il existe ensuite les relations entre les besoins et les autres éléments de modélisation (les block principalement) comme ≪satisfy≫ ou ≪verify≫, mais nous les aborderons dans la partie transverse.

6.5. Les Requirements Diagrams

Quelques exemples de req tirés de http://www.uml-sysml.org/sysml :

6.6. Les considerations sur la Traceability

Une fois que les requirements ont été définis et organisés, il est utile de les lier au moins aux use cases (en utilisant ≪refine≫ par exemple) et aux éléments structurels (en utilisant ≪satisfy≫ par exemple), mais ceci sera abordé dans la partie transverse.

Chaque requirement doit être relié à au moins un use case (et vice-versa!).

6.7. Les Use Case Diagrams (scénarios)

Bien que nous traitions les cas d’utilisation dans la partie comportement, nous les abordons ici du fait de leur proximité avec les requirements.

Ce diagramme est exactement identique à celui d’UML .

6.8. En résumé

6.9. Questions de révision

• Quelles sont les différences entre besoins et exigences ?

7.1. Fondements

On abordera :

• l’organisation du système et des modèles
• les Block Definition Diagrams
• les Internal Block Diagrams
• les Parametric Diagrams (pour les contraintes physiques)
• les Sequence Diagrams (diagramme de séquence système)

7.2. En résumé

En résumé…

7.3. Questions de révision

Pour réviser…

8.1. Fondements

On abordera :

• les Use Case Diagrams (scénarios)
• les Sequence Diagrams
• les State Machines
• les Activity Diagrams

8.2. En résumé

En résumé…

8.3. Questions de révision

Pour réviser…

9.1. Fondements

On abordera ici les aspects transversaux comme :

• la traçabilité des exigences
• les mécanismes d’allocation
• le diagramme paramétrique

Chaque requirement doit être relié à au moins un use case (et vice-versa!).

9.2. En résumé

En résumé…

9.3. Questions de révision

Pour réviser…

1.1. Environnement de développement

Nous sommes des défenseurs des principes [DRY] et [TDD]. Nous allons donc réaliser nos diagrammes dans un outil et non "à la main" (de simples dessins). Nous choisissons ici l’outil TOPCASED pour des raisons que nous expliquerons ailleurs. La version utilisée pour réaliser les exemples de cette section est la version 5.2.

Un outil SysML seul ne suffit pas (cf. Outillage). Il faut penser à la documentation (cf. Génération de doc).

1.2. Spécification du système

Il s’agit ici de décrire le contexte et d’identifier les principaux cas d’utilisation du système.

1.3. Conception du système

Chaque cas d’utilisation sera précisé (seq et act). Les données métier seront alors identifiées pour construire le modèle d’architecture logique (bdd et ibd) complété par la description des comportements complexes (st). Enfin le modèle d’architecture physique permettra de déterminer les aspects déploiement et constructions physiques d'équipements/

1.4. Traçabilité et Allocations

Afin de consolider les différents modèles, les liens de traçabilité qui n’auront pas été déjà décrit
[Il est recommandé de ne pas attendre pour matérialiser ces liens, mais de les exprimés dès que rencontrés dans telle ou telle modélisation.]
seront rajoutés en insistant sur les liens :

• de satisfaction des exigences par les éléments de l’architecture,
• d’allocation des éléments du modèle fonctionnel vers les éléments logiques,
• d’allocation des éléments logiques vers les éléments de l’architecture physique.

1.5. Modèle de test

Nous insistons dans l’ensemble de nos formations sur les approches test-driven, alors nous montrons dans cette section comment participer à la qualité du développement d’un système en formalisant (par exemple avec des diagrammes de séquence de scénarios à éviter) les test et les jeux de test.

2.1. Architecture

2.2. Comportement

2.3. Patrons de conception système

Mérite une section ??

2.1. Quizz

2.1.1. Sujet

Un quizz en ligne est disponible ici (me contacter pour le mot de passe).

En voici une capture d'écran :

2.2. Mots croisés

2.2.1. Sujet

Voici un petit exercice (en anglais pour l’instant, désolé) pour changer :

Vertical (across)

• 2. outside-inside connection
• 4. the full name of a model element is also a … name
• 6. the black diamond in SysML
• 9. History is one of them
• 10. what a block can do
• 13. between states
• 14. a supporter of SysML

Horizontal (down)

• 1. used to describe a flow of actions
• 3. message represented by a regular (unfilled) arrow
• 5. each use case is advised to be linked to at least one of them
• 7. they are handled in SysML by Packages
• 8. communication entity in a seq
• 11. a supporter of SysML
• 12. number of diagrams in SysML